At the most general level, a trading entity is any entity with a membership to an exchange, or an entity that shares a membership in some manner. Trading entities may be a trading house, an individual trader, or one or more groups of traders sharing a membership and otherwise sharing certain resources. Generally speaking then, a trading entity may be an individual trader or group of traders that desire to access markets and engage in market transactions via an exchange.
An electronic exchange typically provides a matching process between traders—buyers and sellers. Typical exchanges are EUREX®, LIFFE®, EURONEXT®, CME®, CBOT®, XETRA® and ISLAND®. Trading entities are typically connected to an electronic exchange by way of a communication link to facilitate electronic messaging between the trading entities and the exchange. The messaging may include orders, quotes (which are essentially two-sided orders), acknowledgements, fills, cancels, deletes, cancel and replace, and other well-known financial transaction messages.
The communication link may utilize numerous telecommunication technologies, including frame relay, X.25, DS-0, T-1, T-3, DS-3 (45 Mb), multiple DS-3 connections, DSL, cable or analog phone lines. The communications links are preferably provided by tier 1 telecom providers and DS-3 ATM connections. The message format and messaging protocols are specific to the particular exchange, and can utilize any protocol. Many exchanges conform to the TCP/IP protocol suite for the transport and network layers. Typically, the exchange provides a standardized communication interface to which the member may connect a workstation, or more typically, a computer network gateway device, through which a number of users may communicate with the exchange.
Many exchanges impose limits or restrictions on the communication messages received from their members or member firms. The limits are generally intended to ensure that the exchange computer system is not overburdened, and to dissuade members from submitting excessive or unnecessary messages. Limits may be enforced in various manners. For example, some limits may be enforced by the exchange queuing (or delaying) transaction messages once a limit has been reached. Another example involves an exchange charging fees or penalties for transaction messages once a limit has been reached. For example, the limits may include a cap on the number of “in-flight” transactions. In-flight transactions are those transactions that have been submitted to the exchange for which the exchange has not provided a return confirmation of receipt.
A further type of limit may be on the number of transactions submitted by a member in a given time period. Orders and quotes indicate a willingness to buy and/or sell, and are often revised and resubmitted by traders to reflect changes in their desired positions. Traders may revise their transactions to reflect even small changes in the market, and when prices in the market move rapidly, this may result in large numbers of transactions being submitted to the exchange. Excessive quoting (which refers to any type of transaction including orders and quotes) can place a burden on the exchange.
Another type of limit that is often imposed by exchanges is the overall aggregate measure of message traffic as measured in bytes in a given period of time. This is commonly referred to as data transmission rate, or bandwidth usage. This limit may simply be a result of the physical limitation imposed by the particular communication link, or it may be a measured quantity.
With the increased use of automated trading tools, reaching or exceeding these limits (e.g., five in-flight transactions on the Chicago Mercantile Exchange, or CME®) may occur rather easily. Indeed, the use of such tools can easily over-burden an exchange's message handling capacity. As such, some exchanges require the use of software at gateways that prevents the message traffic from exceeding specified limits. Some exchanges even provide the software utilities for gateways that connect a member to the exchange. Two example consequences of poor transaction messaging resource use are end user experience delay decay and transaction costs.
Currently, gateway owners don't have the ability to control how the limited messaging resources are distributed among the various users that share the gateway. Thus, software that limits the message traffic without regard to the individual trading entities that may be sharing the communication link has the potential to result in a single user or group of users tying up most or all communications to an exchange. Thus, there is a need to more precisely control the transaction message traffic in view of the limited resources available.